QRZ! Ham Radio 4/QRZ Ham Radio Callsign Database - Volume 4.iso/digests/digital/940081.txt

Internet Message Format | 1994-11-13 | 24KB

Date: Fri, 25 Mar 94 04:30:19 PST
From: Ham-Digital Mailing List and Newsgroup <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: Ham-Digital Digest V94 #81
To: Ham-Digital


Ham-Digital Digest          Fri, 25 Mar 94       Volume 94 : Issue   81

Today's Topics:
                                (none)
                 [REPOST] The # in PBBS addresses....
                       Baycom problem (2 msgs)
                  Ever heard of Yaesu Ft 301???????
                  FROM INTERNET [e-mail]
                                G-TOR
                         Heathkit HD-4040 TNC
                        HF Digital Throughput
                      HP100LX Palmtop & Baycom?
                           KPC-3 and TCPIP

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Ham-Digital Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 24 Mar 94 14:15:52 GMT
From: [e-mail]
Subject: (none)
To: [e-mail]

unsub [e-mail]


                    THANK YOU for your help and reply

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%  Lawrence (Larry) A. Lake          *   Lincoln County R-II School        %
%  208 Redwood Drive                 *   Industrial Technology Department  %
%  Elsberry, Missouri  63343         *   Elsberry, Missouri   63343        %
%  Voice 314-898-5147                *   Voice 314-898-2026 / 898-5553     %
%                E-mail  [e-mail]                  %
%                Packet  kb0lco@k0pfx.#stl.mo.usa.na                       %
%         "Happiness is uniting your vocation with your avocation"         %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

------------------------------

Date: 24 Mar 1994 04:54:23 GMT
From: usc!howland.reston.ans.net!vixen.cso.uiuc.edu!newsrelay.iastate.edu!apollo1.cacd.cr.rockwell.com!zodiac.cca.cr.rockwell.com!newsfeed.ksu.ksu.edu!moe.ksu.ksu.edu!crcnis1.@@ihnp4.ucsd.edu
Subject: [REPOST] The # in PBBS addresses....
To: [e-mail]

[e-mail] (Jeffrey D. Angus) writes:


>In article <[e-mail]> [e-mail] writes:

>  > What's the significance of the # in certain PBBS addresses?  I've seen
>  > them used with some places and not in others.  For example, my own is
>  >
>  > ke4dxa @n4lxi.#nova.va.us.noam.

>                              ^-- North America (Continental Code)
>                           ^----- United States (Country Code)
>                        ^-------- State or Province
>                   ^------------- State sub-divisor (Area)
>            ^-------------------- Destination BBS
>    ^---------------------------- User

>  the # symbol is an area designator. This way nova is not confused
>  with some other location.


Slight correction to the above. The country code in packet radio is
not us, it is usa. They are not the same and us is not acceptable at
this time. There was talk at one time of using us, but it has not been
adopted. On most systems that aren't wildcarded, us will become stuck.

Gary

------------------------------

Date: 24 Mar 1994 07:49:45 -0600
From: ihnp4.ucsd.edu!swrinde!cs.utexas.edu![e-mail]
Subject: Baycom problem
To: [e-mail]

I've just put together a Baycom modem.  The transmit side works fine (tones are
generated and the PTT triggers), but nothing seems to be received.  I've traced
the loudspeaker output through the modem chip and the 74HC14.  The connection
to the computer's CTS line is intact.  My guess is that the computer's 8250
just isn't able to do anything with the 5V signal the 74HC14 produces.  This in
itself wouldn't surprise me, but the documentation with the program suggests
that this isn't normally a problem.  But I've connected the board to three
different PCs now, and none of them receives anything.  Could it be something
else?  Or is signal level mismatch a more common problem than the documentation
would have you think?

73,
Jim


===========================================
Jim Donnett   VE3LXS/G0MVY
Dept. of Anatomy and Developmental Biology
University College London
Gower Street, London, WC1E 6BT
e-mail:  [e-mail]

------------------------------

Date: Thu, 24 Mar 1994 16:06:56 GMT
From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!usenet.ins.cwru.edu!news.csuohio.edu![e-mail]
Subject: Baycom problem
To: [e-mail]

I just went through the same thing.  Watch the CTS out line for data
when the radio is unsquelched and white noise is being fed to the audio
input.  If you are getting data out to the CTS, plug one of those boxes
with the LEDs onto the line.  Do you see the data?

I did.

But I still did not have a response on the screen.

Run DEBUG and use the command "i 3fe".  If you are on a port with a
base address of 3f8, 3fe will be the input status register.  A change
in the returned value will indicate a change since the last read.
I could verify that CTS was working by manually toggling the port
using a breakout box.  So CTS worked.  I was putting data to the CTS
line and the computer was capable of reading it but I was not seeing it.

The solution was in a 25 to 9 pin adapter.  It was a "full" adapter, they
said.  Well, it wasn't.  It was not carrying the CTS through.  Three more
25 to 9 adapters were the same way!  My Logitech mouse plug adapter was
the only 25 to 9 that carried the signal through.

Good luck,
73,
Steve
     [e-mail]
     NO8M.#NEOH.OH.USA.NA

------------------------------

Date: 23 Mar 94 23:53:53 -0600
From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!vixen.cso.uiuc.edu!newsrelay.iastate.edu!cobra.uni.edu![e-mail]
Subject: Ever heard of Yaesu Ft 301???????
To: [e-mail]

Does anyone own a Yaesu Ft 301????   I have one and I was wondering if anyone
else had one.  I guess they are very hard to come by.  Also does anyone have
any ideas on how much the radio and matching power suply would cost? My radio
is in mint condition.     73's


N0ZYA  temp   AG   Waterloo, Iowa

------------------------------

Date: 24 Mar 94 14:55:00 GMT
From: [e-mail]
Subject: FROM INTERNET [e-mail]
To: [e-mail]

HERE IS A LIST OF BOOKS ABOUT INTERNET AT WALDENBOOKS
MOBILE, ALABAMA.

1.   WHOLE EARTH ONLINE ALMANAC - DON RITTNER
2.   ONLINE USERS ENCYCLO. -  BERNARD ABBA
3.   CONNECTING TO THE INTERNET -  AN O'REILLY BUYER'S GUIDE
4.   INTERNET: MAILING LISTS - EDWARD T. L. HARDIE /VIVIAN NEOU
5.   THE INTERNET RESOURCE QUICK REF.
6.   THE INTERNET NAVIGATOR - PAUL GILSTER
7.   NAVIGATING THE INTERNET - GIBBS AND SMITH
8.   THE INTERNET COMPANION -  LAQUEY
9.   RIDING THE INTERNET HIGHWAY -  SHARON FISHER
10.  THE INTERNET ROADMAP - BENNETT FALK
11.  THE INTERNET YELLOW PAGES -  HAHN AND STOUT
12.  THE WHOLE INTERNET USERS GUIDE AND CATALOG- ED KROL
13.  INTERNET:  GETTING STARTED - APRIL MARINE/NEOU AND WARD

I PURCHASED THE LAST BOOK.
ALSO A GUIDEBOOK, ZEN AND THE ART OF THE INTERNET IS AVAILABLE
ELECTRONICALLY, PLUS THERE IS A BOOK OUT BASED ON THE GUIDE,
ZEN AND THE ART OF THE INTERNET: A BEGINNER'S GUIDE. BRENDAN
KEHOE.  THIRD EDITION JANUARY/1994.

VIA N4SO  KEN   [e-mail]

NNNN

------------------------------

Date: 24 Mar 94 19:50:00 GMT
From: [e-mail]
Subject: G-TOR
To: [e-mail]

                       Subject:                               Time:1:46 PM
  OFFICE MEMO          G-TOR                                  Date:3/24/94
Copyright 1994, Kantronics Co., Inc. All Rights Reserved.  G-TOR is a
trademark of Kantronics Co., Inc.  Permission granted by Kantronics to post
on Ham-Digital newsgroup.

                                             G-TOR(tm)
                             The New, Faster HF Digital Mode
                                      for the KAM-Plus
                                                   by
                         Phil Anderson (1), W0XI, Michael Huslig,
                  Glenn Prescott, WB0SKX, and Karl Medcalf, WK5M

On New Year's Day, W0XI and WK5M transmitted a 9,718 byte file from Kansas to
WA4EGT (2) in California on 20-meters in 5 minutes, 20 seconds. The mode was
G-TOR. Immediately thereafter, the file was transmitted again, this time
using Pactor. It took 20 minutes, 15 seconds. Throughout the month of January
these tests were repeated with over one-million bytes transferred error-free.
The average character/second rate for G-TOR was 23.7, for Pactor 8.64 (3).

G-TOR, short for Golay-TOR, is an innovation of Kantronics, Inc. It's a new
HF digital communications mode for the amateur service based somewhat on
concepts outlined in the MIL-STD-188-100 series of documents (4). The error
correction coding outlined in 188-141A (ALE) forms the basis for G-TOR. In
order to keep costs low yet take advantage of concepts prescribed in the
standards, G-TOR makes use of existing multi-mode TNC hardware but
establishes a completely new hybrid ARQ system in firmware.

The benefits of these innovations are:

    o    dramatically increased throughput
    o    apparent reduction in the effects of
          interference and multi-path
    o    low cost

The key features of G-TOR are:

    o    extended Golay forward error correction coding
    o    full-frame data interleaving
    o    on-demand Huffman data compression with run-length encoding
    o    link-quality based baud rate: 300, 200, or 100
    o    2.4 second hybrid-ARQ cycle
    o     fuzzy acknowledgements
    o    reduced overhead within data frames
    o    standard FSK tone pairs (mark and space)

Background Research

It occurred to us after porting Pactor into the KAM that this protocol did
not go far enough. It did not incorporate any of the potential strengths
prescribed by MIL-STD-188-141A. In addition, we knew that commercial and
military systems use forward error correction (FEC) and data interleaving.
So, we decided to evaluate the potential of using FEC coding with
interleaving to increase data file transfer throughput with existing
multi-mode TNCs such as the KAM and KAM-Plus.

We collected signatures of HF error patterns by sending Pactor idle
characters through a DSP-based HF simulator. The simulator was programmed for
various types of channels and conditions. In particular, we gathered error
signatures by using the good, moderate, poor, and flutter fading channels
prescribed by the CCIR (5) as recommended simulator test channels.

We then exclusive-ORed the error patterns with random data files on a PC and
tested various coding schemes. Random data files were Golay encoded,
interleaved, and then mutilated by the error signature. The process was then
reversed; each file was de-interleaved, decoded and the data displayed. We
were encouraged with the results so we moved on to the remaining major design
tasks: designing a robust ARQ protocol and determining whether or not the TNC
could handle the necessary computing task!

Over several months we evolved a protocol that met the challenge. It was
coded and ported into the KAM-Plus and real-time tests were conducted using
the HF simulator. Minor adjustments were made - as in all projects - and we
began on-the-air tests. Tests showed G-TOR to be even better than our
simulator predicted. Through a combination of coding and interleaving, G-TOR
'hangs in there' when channel conditions get tough.


G-TOR Frame Structure and ARQ Cycle

G-TOR operates as a synchronous ARQ mode 1. Regardless of transmission rate,
the cycle duration is always 2.4 seconds, data frames are 1.92 seconds long,
and the acknowledgements take 0.16 seconds. At 300 baud, each data frame
contains 69 bytes of data, one control byte, and a two byte CRC. At 200 baud
the frame contains 45 data bytes, and at 100 baud 21 data bytes.

Synchronization is established during the linking phase when the calling
station (master) sends a G-TOR frame containing TO and FROM callsigns. The
information receiving station (IRS), while in standby, synchronizes to the
frame by searching for its callsign. Once in step, it acknowledges such to
the master and sends <link established> to its terminal. Transmission of data
may then begin. Sufficient time is left between the end of the data frame and
the start of the acknowledgement for propagation between stations over an HF
path. A change in information flow direction (changeover) is accomplished by
extending the acknowledgement bytes into a changeover frame. Once
acknowledged by the other station, changeover is complete. Link quality,
dictated by the number of consecutive good or bad frames received, determines
link speed.

The effective performance of stations, while communicating over adverse HF
channels, relies on the combined use of forward error correction,
interleaving, and redundancy. These tools for improvement are incorporated in
G-TOR within the firmware of the KAM-Plus (or KAM with enhancement board). We
adopted an extended version of the (24,12) Golay code for G-TOR.

Procedures for data formation, transmission, reception, and data recovery are
outlined below. Prior to transmission, 300 baud frames are divided into 48
12-bit words and matched with 48 error correction words of 12 bits each. The
entire 72 byte data frame is then interleaved bit by bit, resulting in 12
bins of 48 bits, and transmitted . Upon reception by the IRS, the reverse
process is carried out. The frame is synchronized, de-interleaved, decoded,
and checked for proper CRC. If the frame is found to be in error, the IRS
will request that the matching parity frame be sent. Upon receipt, the parity
frame is  used in combination with the data frame in an attempt of recover
the original data bits. If unsuccessful, the ARQ cycle begins again. The
dispersement of noise-burst errors via interleaving and the power of the
Golay code to correct 3 bits in every 24 usually results in the recovery of
error-free frames.

On-The-Air Testing

During the month of January over a million bytes were transferred error-free
from Lawrence, Kansas to Laguna Niguel, California. During these tests, TRACE
was set ON at each station, enabling the display of acknowledgement bytes and
data frames including control bytes. This allowed us to view and count data
and acknowledgement frames received with and without the aid of forward error
correction and interleaving.

The results were somewhat surprising! While Pactor often dropped in
transmission speed from 200 to 100 baud, G-TOR nearly always kept on
crunching frames at 300 baud! Enough frames are corrected to keep the system
running at 300 baud, regardless of man-made interference and mild multi-path
conditions. This was apparent as G-TOR seldom dropped automatically from 300
to 200 baud. Transfer duration for the entire test file varied from 12 to 27
minutes for Pactor but only 5.5 to 7.5 minutes for all but one transfer in
G-TOR. G-TOR simply maintained its highest pace better, resulting in a
substantial increase in average throughput.

Operation of G-TOR is much like AMTOR. You enter G-TOR standby by typing
<GTOR> and <return> in response to the cmd: prompt. From standby you can copy
AMTOR FEC (also used as the calling mode for G-TOR CQs), or wait for a G-TOR
link request from another station. To initiate a link with another station,
you must type <GTOR callsign return>. The link is then established and the
TNC reports <linked to callsign>. During a QSO, changeover is dictated by the
usual keyboard (or host-mode) directives, <control-C T> and <control-C E>.

Conclusion

G-TOR features include Golay forward error correction coding, full-frame
interleaving, on-the-fly Huffman data compression with run-length encoding,
fuzzy acknowledgments, a long ARQ cycle of 2.4 seconds, and a link-quality
based transmission rate. Combined, these techniques result in a new, very
robust, interference-resistant, and existing equipment compatible mode for HF
digital communication for the amateur radio service. Throughput exceeds other
existing all-mode TNC modes by better than two-to-one. G-TOR is not available
for KAMs without the enhancement board since EPROM space has been used up.
G-TOR is now standard in the KAM-Plus and the Enhancement Board for the KAM
(predecessor of the KAM-Plus).


1. Kantronics Inc., 1202 E 23rd Street, Lawrence, KS, 66046, 913-842-7745,
fax [phone].

2. Towle, Jeff, InterFlex Systems, PO Box 6418, Laguna Niguel,CA, 92607.

3. Van Der Westhuizen, Mike, ZS6UP, "A Practical Comparison Between Clover
and Pactor Data Transfer Rates," CQ, February, 1994.

4. Military Standard (MIL-STD) series -188-100, containing standards common
to long-haul communications, Department of Defense. Specifically
MIL-STD-188-141A, Interoperability and Performance Standards for Medium and
High Frequency Radio Equipment.

5. Recommendations of the CCIR, 1990, Volume III. (Fixed Services at
Frequencies Below About 30 Mhz), Recommendation 520-1, page 28.


G-TOR is a trademark of Kantronics, Inc.

------------------------------

Date: 24 Mar 94 21:32:44 MDT
From: ihnp4.ucsd.edu!dog.ee.lbl.gov!hellgate.utah.edu!cc.usu.edu![e-mail]
Subject: Heathkit HD-4040 TNC
To: [e-mail]

In article <[e-mail]>, [e-mail] (Kim Leong) writes:
> I don't think my original post made it into this group so I'm
> re-posting.
>
> I have a Heathkit HD-4040 TNC that I built and had in service about 8
> years ago.  I have been off packet for about 6 years.  I dug the TNC out
> of its burial box and am interested in getting back on packet with it.
> The question I have is if there are some firmware or other updates
> anyone knows of that should or can be done to the HD-4040.
>
> Thanks,
>
> Kim Leong - WA6QQF
> BBS:  Sysop @ [phone]
> Internet:  [e-mail]

I use two HD-4040's...got 'em for about 25 bucks each, and one has a TAPR TNC-2
upgrade (DCD decoding too), and the other one has the WA7MBL firmware in it.
They both work great! (I have the TNC-2 clone running KISS, and use JNOS)

If you can get the upgrade, I would seriously consider it...Don't bother with
the WA7MBL code (It is quality stuff, but no KISS mode)

--
-------------------------------------------------------------------------------
Daniel D Holmes          "                " -  Marcel Marceau
Internet:  [e-mail]
AmprNet:   N7NKR @ N7NKR.HOME.AMPR.ORG 44.40.1.43  [located in Salt Lake City]
           N7NKR @ N7NKR.AMPR.ORG      44.40.12.10 [located in Logan]

------------------------------

Date: 24 Mar 94 20:04:07 GMT
From: [e-mail]
Subject: HF Digital Throughput
To: [e-mail]

                       Subject:                               Time:1:52 PM
  OFFICE MEMO          HF Digital Throughput                  Date:3/24/94
Based on published test data, here is my reading on the typical throughput
(characters per second) to be expected from several HF digital modes:

RTTY                   6
AMTOR (ARQ)       5
Packet AX.25       4
PacTOR              10
G-TOR                25
CLOVER II           50

Note that Huffman data compression is available in the PacTOR and G-TOR
protocols to increase throughput for certain data.  Note also, that these
throughputs are not normalized to occupied bandwidth.  If one looks at
characters per second per hertz there are even more dramatic differences.

73/Rick W0TN <[e-mail]>

------------------------------

Date: Thu, 24 Mar 1994 16:24:28 GMT
From: ihnp4.ucsd.edu!galaxy.ucr.edu!library.ucla.edu!agate!usenet.ins.cwru.edu!news.csuohio.edu![e-mail]
Subject: HP100LX Palmtop & Baycom?
To: [e-mail]

Steve Wolf ([e-mail]) wrote:
:
: Has anyone been able to get Baycom to work on the Hewlett Packard
: 100LX palmtop?  After externally powering the Baycom, I was able
: to transmit readable packets.  However, it does not appear that
: the HP is reading the CTS line.  I have verified that data is
: going to the CTS out.
:
: There is a pretty good user support group on comp.palmtops and HP
: seems interested in any application it can be put to.  I wanted to
: check here first.
:
: Also, the paltop runs the MSYS BBS without a complaint.  Running with
: 300 message slots and about 500 BIDs left me over 150k free (so I could
: make lots more slots and BID space).
:
: Interesting that a 80188-based machine can run the serial port at
: 57k yet we have to watch our BBS phone ports for dropped characters.
:
: 73,
: Steve
:      [e-mail] < works better
:      NO8M@NO8M.#NEOH.OH.USA.NA
:


     The solution to this problem was not easy.  I verified that
the HP was seeing CTS (through reading the status register) and
that the Baycom was sending information through a meter.
     It turned out that a problem I had before came back.  A
9 to 25 adapter did not carry the signal through.  Three of them
didn't.  Only the Logitech adapter for my mouse worked.  I now
have those marked as problems.

73,
Steve
     [e-mail]
     NO8M@NO8M.#NEOH.OH.USA.NA




------------------------------

Date: 23 Mar 94 23:07:52 GMT
From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!darkstar.UCSC.EDU!nic.scruz.net!cruzio!comix![e-mail]
Subject: KPC-3 and TCPIP
To: [e-mail]

In article <[e-mail]> [e-mail] (Dave Parker) writes:
>One thing to consider is there is no upgrade for 9600 bps on this
>TNC, look at the DRSI DPK-2 at least it has a modem disconnect
>header so you can use an external high speed modem later if you wish.
>Its priced roughly in the same ballpark as the KPC-3.
>Dave, KD6RRS

This is a plug.  I just bought an AEA PK-96.  This is a new TNC.
It's a combination AFSK (1200 baud) and FSK (9600 baud G3RUH) tnc.
In theory, you can have it all in one package.  No ripping out
the disconnect header every time you switch.  I overpaid at $190
but am not complaining.  It draws 400ma at 13.6v (3.5w) so it's
not exactly suitable for battery operation.  Too soon to tell if
it's any good.  Anyway, it is possible to buy a TNC that will do
both 1200 and 9600.  IMHO, tcp/ip should be run at 9600 and not
1200.  It's just too slow.


--
# Jeff Liebermann   Box 272     1540 Jackson Ave     Ben Lomond    CA   95005
# 408.336.2558 voice  wb6ssy@ki6eh.#nocal.ca.usa  wb6ssy.ampr.org [44.4.18.10]
# 408.699.0483 digital_pager    73557,2074  cis [don't]
# [e-mail]  scruz.ucsc.edu!comix!jeffl

------------------------------

Date: 24 Mar 1994 15:49:04 GMT
From: ihnp4.ucsd.edu!swrinde!elroy.jpl.nasa.gov!ncar!csn!col.hp.com![e-mail]
To: [e-mail]

References <2mksi3$[e-mail]>, <2mnbtp$[e-mail]>, <[e-mail]>│π
Subject : Re: KPC-3 and TCPIP

: >KPC-3 is excellent value for the money.
: If you only want to go 1200 baud it's fine and if you want to keep the same
: EPROM in it it's fine.  But if you ever want to modify it for high speed
: or DCD or KISS only you'll regret buying as I did.

: Just my opinion and expierience,
: 73, Nate

The KPC-3 already has KISS capability.

Mike, K0TER

------------------------------

End of Ham-Digital Digest V94 #81
******************************